COMMENT ⊗   VALID 00021 PAGES
C REC  PAGE   DESCRIPTION
C00001 00001
C00004 00002	Summary of suggestions, bugs, etc., from subsequent pages:
C00008 00003	∂11-Sep-78  1549	DON 	follow mr_entrants, multiple masks
C00009 00004	∂15-Sep-78  0224	RSP  	Typing ↑-chars on non-displays
C00010 00005	∂05-Oct-78  2310	RSP  	/OPT(#) nuisance re TMPCOR
C00012 00006	∂22-Oct-78  2212	ROD  	ARRAY no room 
C00014 00007	∂21-Jan-79  0619	MRC  	ESC-I interrupts   
C00015 00008	∂15-Mar-79  1825	RP  	PRUNEing with DIRED 
C00025 00009	∂13-Apr-79  1024	DGL  	interdevice transfers
C00027 00010	∂19-Jun-79  1634	ME  	[*,*]
C00029 00011	∂14-Aug-79  0434	DON  	possible bug in interPPN renames  
C00035 00012	∂21-Aug-79  1331	ME  	changing terminal types  
C00037 00013	∂15-Oct-79  1230	BTH  	mail & send
C00038 00014	∂03-Feb-80  1300	MRC  	CLRBFI on errors?
C00039 00015	∂08-Apr-80  1725	ME  	window positioning on mask change
C00047 00016	∂03-Aug-82  1219	ME	rename fails to zero dump word
C00048 00017	∂28-Jan-83  1728	PB	output files on udp
C00049 00018	∂04-May-83  1452	ME	/unsorted /=> /-tmpcor
C00050 00019	∂24-Nov-83  1524	JJW	Continue after exit in file-display mode
C00051 00020	∂02-Jan-84  1711	ME	dealing with Bad Retrieval
C00052 00021	∂07-Jul-84  1545	ARK	COPY
C00053 ENDMK
C⊗;
Summary of suggestions, bugs, etc., from subsequent pages:

IMPLEMENTED BUT UNTESTED AND/OR UNANNOUNCED:


INTENDED TO BE INCLUDED IN NEXT RELEASE:


RELATIVELY HIGH PRIORITY CONSIDERATIONS:

Document or fix the fact that exiting while in file-display mode gets you
	out of file-display mode, in case you then CONtinue.
More details in error messages, e.g. when can't read file for ⊗∃.
Allow deletion of files with bad retrieval (don't bomb out!).

REASONABLE SUGGESTIONS AND IDEAS:

Decide what to do about mask changes and window position.  Might include:
Maybe remember last n masks and have ⊗#αβM load #th into line editor (except
	that ⊗0αβM just types it, since αβMα<cr> loads it up).
Consider whether ⊗O file should default to mask device or to DSK.
Marty would like a mode that remembers only files that match the mask (perhaps
	refusing to do renames) so that [*,*] will work.
Add undelete (/undo/und/⊗u).
Perhaps have /OPT(#), as opposed to /OPT=xxx, not override use of tmpcor.
	Likewise for /UNSORTED.
"Description" field a la PRUNE?

MISCELLANEOUS SUGGESTIONS AND IDEAS:

TVR would like us to handle multiple devices at once; particularly hard given
	the present method of dealing with track_size.
DGL wants interdevice renaming!
Extended one-line MAIL & SEND?
Full searches should include optional field-specs.  Also remember funny
	activators (such as αβD).  Extended F can force_feed them via
	special_flag etc.  Note: In E, ⊗Fxxx<ALT> sets up xxx as search string
	for ⊗*/⊗F<cr>.  Should have extended F command in addition to FIND.
Handle terminal changing type.
Command to find most recent of mr_entrants.  Or nth most recent.
Command to copy a file.
Some form of E's ⊗N command.
Do something about doc'n lines in which ↑<letter> causes >80 chars on ttys.
Eventually switch to our own internal storage allocation.  Say, allocate records
	containing large arrays within which we do our own management, using
	hrrz(flags)=0 to indicate a free record and hlrz(flags) as a pointer to
	the next free record.  By allocating string arrays similarly for the
	filestr's, we can make sure the string gc stays happy.
Safe arrays, general cleanup, merge frequently occurring chunks of code, etc.
Try to handle core overflow more gracefully.  GOGTAB['73] = '776000 means can't
	get more core, and GOGTAB['74] > '775000 means will soon try.
∂11-Sep-78  1549	DON 	follow mr_entrants, multiple masks
(1) Maybe add new command that finds last file that changed pages, on page it
    got added to.  Similarly for last n files that changed pages.
(2) Remember the last n masks and allow user to get them loaded into line
    editor.

∂15-Sep-78  0224	RSP  	Typing ↑-chars on non-displays
CHECK DOCUMENTATION FILE TO BE SURE THAT CONTROL CHARS NEVER
EXPAND THE LINE ON A TTY TO BEYOND 80 TTY CHARS.

Foo!  It's bad enough that we have to watch out for lines overflowing due to ↑V
and whatnot, but we also aren't doing tabs right in such cases!  And even if we
did, it wouldn't work!  Try TYPEing page 2 of the file on such a terminal for a
sample...

∂05-Oct-78  2310	RSP  	/OPT(#) nuisance re TMPCOR
Due to the presence of "/OPT(#)" in the invocation line, DIRED forgets the
previous run's mask and sort parameters (i.e. doesn't use TMPCOR).  This is a
nuisance when running on non-displays if you wish to use our macro to print out
an entire NORMAL page -- you have to remember to re-type the full mask and sort
parameters or you will get the ones specified by your main OPTION.TXT line.

Perhaps "/OPT(#)" instances should not count towards whether TMPCOR should be
ignored.

don - Org!  Easier said than done, and also a bit strange, since DR/O is the way
I like to invoke DIRED to make sure I don't get stuck with an old mask.  But I'm
sure we can come up with something.

∂22-Oct-78  2212	ROD  	ARRAY no room 
A mask of *.dmp[1,*] loses with a SAIL error about an array being too
small - should lose more gracefully or not at all - also *.*[*,*] loses
similarly if you can't make the first one lose.

DON - The error is "ARRAY no room", which means not that the array is too
small but that there's no room to allocate it at all.  This is a tricky
problem to get around gracefully (the documentation (under "coming
attractions") notes that the current limit is about 1600-1700 files;
and this limit is on total number of files in the directories read,
even if not all of the files are being displayed) and I believe even
E simply says "I just got too bloated!" and bombs out if it hits 254P.
But we'll try to think of a way to handle it more cleanly.

∂07-Apr-80  0935	AAM  	PC exceeds mem bounds   
.drd login.*[??,??]
? Error in job 33
PC exceeds mem bounds at user 136015
↑C
. 

DON - 
DIRED needs to maintain, in core, complete information from all directories
read.  Since [??,??] matches quite a few, it ran out of core, and stepped all
over itself due to SAIL's lack of good core-overflow trapping.  One of the
things on our list is cleaner handling of this situation, but we're not sure
how to go about it.

∂21-Jan-79  0619	MRC  	ESC-I interrupts   
It would be nice if ESC-I interrupts were implemented in DIRED.

DON - Well, we've considered that, but so far we haven't come up with anything
to use them for.  What'd you have in mind?

MRC - Stop a command in progress and try to return to the state before the
command was done.  Some commands take a long while, like ⊗∞P in ∃ mode.

∂15-Mar-79  1825	RP  	PRUNEing with DIRED 
What I came up with might not represent a large change to DIRED (as if you
don't have enough to keep you busy):

The essence of it would be a αX PRUNEUPDATE command.  This command would
look for a file named (for example) PRUNE.DAT on the user's area (or one
on the area specified by the mask).  (It could also look for an explicitly
named 'prune' file, of course.)  It would then add, delete, or rename
entries in the PRUNE.DAT file according to the actions in DIRED's action
list.  The user could then go in and append comments to the PRUNE.DAT file
using E.  - Rob
--------------------
It's conceivable, but not terribly enticing.  What happens if someone
deletes or adds files other than with DIRED?  In other words, you make it
sound so simple, but really the mods to PRUNE.DAT are based on much more
than just the action lists pending in DIRED.  What you suggest is really
tantamount to comparing one DIRED data structure with another, and I'm not
particularly interested.  I'll put your idea in the list of suggestions
for DIRED, but don't hold your breath.

Note that, aside from updating PRUNE.DAT for renamed files, what you want
could just as easily be done by a slight mod to PRUNE to come up with a
program which updates PRUNE.DAT by deleting entries for missing files
(which PRUNE already does) and creating blank entries for new files (which
PRUNE currently refuses to put into PRUNE.DAT) and then swapping to E.

(from BBOARD):

∂12-Apr-79 ROB	20-Apr-79 DON	PRUNE file format
PRUNE's usefulness would be enhanced if the format of the filenames in
PRUNE.DAT files were acceptable to E's αXPOINT command.  This way, starting
with PRUNE.DAT as a home file, a user could easily peruse a directory area.

REM - I have gotten used to the current PRUNE.DAT format, rely on it for
maintaining one-line documentation of all my files since 1971.

DON - But presumably it wouldn't hurt if the filename/extension fields were
merged into a single filespec?

ME - That filespec would have to include the PPN to really make POINTER work
in E.  And PRUNE would have to be fixed to handle either old format or new....
Actually, I think DIRED is a better way to peruse a disk area, using the ⊗∃
command, and when necessary (to get some particular features of E lacking
in DIRED, like file searching or displaying whole long page) swapping to E
on a given file.

REM - PRUNE organizes files according to extension rather than
first filename.  If you made the whole thing one field, presumably
with period separating them, PRUNE.DAT sorted by extension would
be quite ugly and unparsable.

ROB - DIRED isn't what I want because:
1) I don't have the documentation about what each file is about in the
   DIRED display.
2) Using the ⊗∃ command, I can't edit the files I am perusing.
3) Using the ⊗ε command, there is a big kerchunk every time I want to get
   back into DIRED from E.
I don't care about the beauty and parsability of PRUNE.DAT.  I want an easy
way to maintain my files.  Maybe PRUNE needs a /UGLY switch for this?

ME - What we REALLY need is for DIRED to be able to maintain a file called
DIRED.DAT, similar to PRUNE.DAT, and to be able to display (and edit, of
course) the comment associated with a file instead of all the (or
w/selected) data for that file.  Maybe DIRED could even use and maintain
PRUNE.DAT itself, but I'm not sure that's a good idea.

KS - I'm sure we'll be informed that DON&RSP have a DIRED list as long as ME's
fabled E list, and which already contains ME's idea (or something better).  But
I agree that a complete DIRectory EDitor should have this hypertext comment
facility.

DON - It's been suggested, but was sufficiently unrelated to the existing
features in DIRED that it didn't make the "list".  It's really the sort of
thing that falls under the auspices of a combination of E and DIRED, so I
suspect it falls under the infamous heading: "next system (S1)."

ME - No, No, No.  If PRUNE can do it, then DIRED should be able to.  After
all, DIRED is to PRUNE as E is to SOS (yes, I know some features of SOS do
not exist in E...).  It's just that no one thought of PRUNE as a
"directory editor", but it is, after all (it can delete files, for
instance).  If this feature were in DIRED, we could do away with PRUNE
(except maybe for non-displays, but maybe even for them...).  I again
suggest being able to display the PRUNE-type comment along with each
filename, as just one more field of the display (of admittedly arbitrary
length).  And allow editing the field with the line editor.

DON - Sigh, okay already, I'll put it in the DIRED wish list.

∂26-Jul-79  1153	SL  	DIRED & PRUNE  
Re Inter-PPN renaming in DIRED, have you considered introducing a means of
carrying PRUNE entries from the old to the new area.

DON - There's no way we're gonna poke around inside PRUNE.DAT to move around
individual lines.  It's been suggested that DIRED should include a description
file, thereby making PRUNE obsolete; at that point we would certainly do as
you suggest.  But it's a ways down the road.

ME - I have an old feature request for Dired that I'd like to bring back
to the surface, namely the ability within Dired to have text (comments,
descriptions, whatever), associated with each filename on an area,
presumably kept in one file for each disk area.  The text should be
of indefinite length and displayable in variable amounts by Dired.
For instance, for looking a long comments, there might be a "comment
display mode", like ⊗∃, where it displays a long comment for one file.
But also it should be able to display 1 to n lines of comment per file.

Now, that I've refreshed your memory about this, let me say that I have
a volunteer to do it, or at least look into doing it, if you yourself
don't want to.  He's Jskud.  I guess you know him.  If you want to do
any level of work in creating this feature, that's fine.  If you want
simply to be consultable by him while he does it, that's fine.  Of if
you want to work with him or do it by yourself, that's OK, but I would
like to get it done one way or another.  What do you say?

He wants to learn about SU-AI and do something useful at the same time.
If you have any other ideas for him to think about in this respect, let us
know.

∂13-Apr-79  1024	DGL  	interdevice transfers
It sure would be nice...
	...if DIRED could transfer files.  I tried a rename of
a DSK file to UDP2: and it barfed on the ":".  Any suggestions?
	-Gareth
--------------------
Interppn renames are here, but interdevice transfers are extremely unlikely.
(At present you can't even have multiple devices in the mask, let alone rename
from one to another.)  We'll keep it "on the list", but don't hold your breath.
(I trust you're aware of the TRANSFER command.)

∂13-Apr-79  1545	DGL  	I found an interim solution: 
	to interdevice transfer: mask for files to be transferred,
αO FILNAM in /FOONLY mode, and TRANS DEVICE:←@FILNAM.

∂19-Jun-79  1634	ME  	[*,*]
I want to be able to use DIRED to generate a list of all files with a
particular pattern (e.g., specific extension) anywhere on the disk (i.e.,
on [*,*]), but DIRED insists on keeping in core all of the UFDs it has
ever seen.  I would like a mode in which DIRED only remembered the files
that matched the mask.  This would make it enormously more useful.  I
don't even care if in this mode DIRED refused to do renames or if it
always reread destination UFDs to search for conflicts.

DON - Since this would entail a major revision to the way DIRED handles things,
and since we don't have that much spare time, it's not likely to happen in the
near future.  (Among other problems, the code that decides whether a file
matches the mask and should thus be displayed is currently completely separate
from, and called long after, the code that reads ufds.)  We'll add it to the
"list" though.  Meantime you should use WILD, which has more flexible patterns
anyway.

∂14-Aug-79  0434	DON  	possible bug in interPPN renames  
I renamed two files to other directories and then changed protection on them
from 0 to whatever.  DIRED didn't object, but when I ran the action lists it
failed to do the protection changes.  This is, on further thought, correct --
both target directories have directory protection prohibiting other users from
changing protection on files.  The question is, why didn't DIRED object when I
did the ⊗π?  I suspect we're not re-evaluating the legal-ops bits when we do an
interPPN rename.  This may in fact have been a conscious decision once; I seem
to recall deciding that, since if the ⊗π were done first we wouldn't want to
re-evaluate whether it was legal in light of the rename, there was no point in
checking it in the other direction either.  We should think some more about
whether there's a clean way to handle this.

3-May-80: Further notes.  Even when it's possible to do both the rename and the
prot change, there's no simple rule for deciding how to manage it.  E.g., we may
have to change the protection first, since once we do the rename we may not be
able to.  Or we may have to rename first, because the new protection will
prohibit it.  Bleah!  Also note related bug below, which has been evaded
in DIRED by a long-term (but hopefully temporary) kluge.

AAM - You're right, of course.  I hadn't really thought about the "rename before
or after" problem.  Just out of curiosity -- isn't a protection change really a
rename?  What does WAITS do if you change both the name and the protection
as part of a single rename?

∂20-Sep-81  1201	DON  	RENAME bug    
; According to the UUO manual, a successful RENAME does not close the file
; (though the file may have been closed prior to the RENAME).  Well, the
; following program shows a strange lossage: it creates a file, then releases it
; and reopens the channel and looks it up (to get a fresh start).  It then does
; a rename to another ppn, followed by another rename to change the protection.
; The second rename fails with code 2, even though there should be no protection
; violation involved (in EITHER directory!).  In fact, as the program then goes
; on to demonstrate by again releasing and reopening the file, it is perfectly
; capable of doing the protection change -- it just doesn't work without the
; extra lookup.  Note: the bug occurs only if the first rename changes the ppn.

	title	bug

st:	open 0,[17 ↔ 'dsk   ' ↔ 0]
	 halt
	move 10,['bugfil'] ↔ hrlzi 11,'tmp' ↔ hrlzi 12,5000 ↔ move 13,['  1don']
	enter 0,10
	 halt
	releas 0,
	open 0,[17 ↔ 'dsk   ' ↔ 0]
	 halt
	move 10,['bugfil'] ↔ hrlzi 11,'tmp' ↔ hrlzi 12,5000 ↔ move 13,['  1don']
	lookup 0,10
	 halt
	move 13,['  tdon']
	rename 0,10
	 halt
	tlc 12,405000
	rename 0,10
	 jrst [outstr [asciz/Second RENAME failed, code /]
		addi 11,"0"
		outchr 11
		outstr [asciz/
/]
		jrst .+1]
	releas 0,
	open 0,[17 ↔ 'dsk   ' ↔ 0]
	 halt
	move 10,['bugfil'] ↔ hrlzi 11,'tmp' ↔ hrlzi 12,5000 ↔ move 13,['  tdon']
	lookup 0,10
	 halt
	move 13,['  tdon']
	tlc 12,405000
	rename 0,10
	 halt
	outstr [asciz/Tried again and it worked!
/]
	releas 0,
	open 0,[17 ↔ 'dsk   ' ↔ 0]
	 halt
	move 10,['bugfil'] ↔ hrlzi 11,'tmp' ↔ hrlzi 12,5000 ↔ move 13,['  tdon']
	lookup 0,10
	 halt
	move 13,['  tdon']
	movei 10,0
	rename 0,10
	 halt
	exit

	end st

∂21-Aug-79  1331	ME  	changing terminal types  
 ∂13-Aug-79  1712	DON  	wow!
The DM I was working from flaked out, so I turned it off and found another
and attached my old job to it.  I had been sitting in E, so I typed <esc>
to get the screen redrawn.  Instead, it gave me the non-display form --
current line and position.  That's obviously the right thing to do since
I hadn't told the system I was on a DM on this new terminal -- DIRED
wouldn't be that clever!

ME - When about to update the display, E does a PPINFO UUO to find out if
PP #1 is still selected and positioned properly.  If not, it calls DPYCHK
to see if the user has changed TTYs or terminal types and then redraws
everything, as appropriate to the new TTY.  E also takes Terminal-Type-Change
interrupts, which force calling of DPYCHK; I think these interrupts only
occur upon TTY DM or TTY NO DM, or something like that.

∂15-Oct-79  1230	BTH  	mail & send
You probably have this suggestion already, but just in case:
How about ⊗xmail and ⊗xsend from dired?  Perhaps just for command
line messages.

DON - No, we didn't have those on the list -- someone once suggested ⊗xrun,
but that's as close as anyone's come.  Hmm, I can see why you want them,
but don't hold your breath.  I'll put them on the list.

∂03-Feb-80  1300	MRC  	CLRBFI on errors?
DIRED should do a CLRBFI when an error happens.
--------------------
Not clear.  E doesn't -- and shouldn't, since some errors are expected, like
typing 99P to get to end of file.  Don't know if that reasoning applies to
DIRED.  Will put it on the list and think about it.

∂08-Apr-80  1725	ME  	window positioning on mask change
If the old current file is in the new mask, then you position that line
at the top of the new window.  I would much rather see it positioned
in the middle.  I don't think there is any reason for positioning at the top.

DON - I'm confused.  I just tried it by looking at *.*[1,DON], positioning
myself at CKSUM.DAT four lines below the top of the window, and when I changed
the mask to *.∃∃∃ I was left at CKSUM.DAT at the same position in the window.
Again, please give me a specific example.

ME - Right, you just described the problem.  When you change the mask, there
are usually a different number of files displayed, quite often less than
a screenful, so the arrow is forced higher in the window.  Then when you
change back, the arrow is kept high, I guess, where it was, and the original
window position is really gone.  I don't think there is a guaranteed way
to win, short of retaining every mask that has been used and the last
window position under that mask, which I certainly don't advocate.  But
what I often do is start with a mask of *.* on some area (sorted by -date,
so I'm really looking at recent files), then give a specific mask that
matches only 3 or 4 files.  At that point, I'm often left pointing to the
first of those files (unless I was already pointing to one of the others
of them before?).  Then maybe I delete one or more of the small group
and change the mask to look at the entire area again.  At that point,
I'm pointing to the last file I just happened to be positioned at under
the other mask (say the first file I didn't delete), and since the previous
mask list was small, that file is probably positioned at the top of the
window, obfuscating all the MORE RECENT files (remember -date) which
are the prime ones I'm interested in.  Now I supposed I can do a ⊗-⊗J
or something, but it loses this way EVERY TIME, so it seems the algorithm
could be improved, like by not retaining the window on substantial changes
to the mask (or something) where the previous mask all fit on the screen
but the new one doesn't (pardon my terminology).  Understand?

∂09-Apr-80  1207	DON  	how much is that buggie in the window? 
Ah, in other words it works as planned, but sometimes to ill effect.
Yeah, I've had similar frustration when I delete a file, then do a
⊗XCANCEL, and the newly restored file is added above my current
position, usually above the top of the window.  Not clear what sort
of heuristic to use to take care of this and/or the mask-changing
case; I'll think it over and get back to you.

∂09-Apr-80  1520	DON  	death of the read mask  
Way back when RSP and I were designing DIRED's command structure, we tried to
decide what the arrow line should do when the sort key changed.  We decided
that, in general, it should stay at the same file in the same window position
(if possible), but that there were times when the user might want to be at the
top of the newly-sorted list.  We considered having ⊗#⊗S...<cr> do a ⊗#⊗L after
sorting, or having ⊗S...αβL do a ⊗1⊗L after sorting, but we decided that it
wasn't worth the extra confusion, since it's almost as fast to do ⊗S...<cr>⊗L
explicitly.  (It's not so nice on a DM, but only because we still haven't gotten
around to implementing aborted displays.)

The same thing applies here with the Mask command.  That is, it's a lot easier
to get to the top of the page after changing the mask than it is to get back to
where you were if DIRED decides for you that you want to be elsewhere.  Havng
DIRED decide to do a ⊗-⊗J for you is less destructive, but perhaps even more
disconcerting.  And I still don't have any good heuristics for the threshhold
when one would "want" this to happen.

What I'm thinking of doing instead is giving higher priority to the "mask stack"
idea that's been on my list for a while.  The idea was to have ⊗#αβM load up the
line editor with the #th previous mask, let you edit it, and take the resulting
text as a new mask.  What I could do is (a) check the eventual input against
what was loaded into the line editor, and if they are identical then (b) do a
αL, αF to find the file you were at when you last had that particular mask, and
⊗#⊗∧ to attempt to position the file in the same window location.  Storing the
file name and "∧"-value for each mask isn't much trouble, since I'd be using
SAIL's dynamic string allocation anyway (and I'm not likely to overflow the max
string length!).

How does any of this sound to you?

∂03-Aug-82  1219	ME	rename fails to zero dump word
When a file is renamed, its dump word gets zeroed, but Dired doesn't seem
to realize this.  At least, for a file that's been renamed (α. typed after
renaming cmd given), Dired still displays the previous Dumped information.

DON - Also check what other conditions affect file info, e.g., reprotect?

∂28-Jan-83  1728	PB	output files on udp
It seems that if you ask for an output file without specifying a device
while the file mask (i.e. display) is of a udp, the file gets written to
udp (i guess the file mask device is assumed).  I think that's bad, cuz
one expects commands to default to dsk.  The documentation doesn't say,
in the section about output, what the default is, far as i can tell.

∂22-Feb-83  1527	TVR	/OUT command 
After saying DRD UDP1:[3,TVR], the command /OUT writes its file on
UDP1: instead of DSK: if no device name is explicitly given.  This
seems different than device defaulting in most programs.

∂04-May-83  1452	ME	/unsorted /=> /-tmpcor
DIRED/unsorted should use the last DIRED cmd (mask, etc.) instead of doing
a DIRED * (or whatever option.txt says).

∂24-Nov-83  1524	JJW	Continue after exit in file-display mode
If you αE (or αXQUIT) from DIRED while in file-display mode, and then
type CONTINUE, you don't get back into file-display mode.  This should
be documented, or perhaps fixed if you consider it a misfeature.

∂02-Jan-84  1711	ME	dealing with Bad Retrieval
Uh, deleting a file with bad retrieval would also be nice, although
not so important.  I think what you do is do the RENAME even though
the LOOKUP lost.  COPY asks the user if he wants to try to delete
the file anyway.  DIRED could do that or just say Delete failed.  Uh,
also would be nice if DIRED said why it is "Unable to read FOO".

∂07-Jul-84  1545	ARK	COPY
It would be nice if there were a copy command (to copy a file), especially
if it preserved the write dates, program, and writer.